Multilevel Contracts for Trusted Components

This article contributes to the design and the verification of trusted components and services. The contracts are declined at several levels to cover then different facets, such as component consistency, compatibility or correctness. The article introduces multilevel contracts and a design+verification process for handling and analysing these contracts in component models. The approach is implemented with the COSTO platform that supports the Kmelia component model. A case study illustrates the overall approach.Comment: In Proceedings WCSI 2010, arXiv:1010.233

Enhancing Component Specification by Behavior Description − the SOFA Experience

This paper aims at sharing with the reader the experience with behavior protocols- the component behavior description introduced in our SOFA component model and emphasize the key research challenges we have faced in this respect during its 6 years existence and development. In particular, this includes the issue of finding the “right ” semantics of fulfilling the behavior contract in terms of both horizontal (client-service) and vertical (nesting) cooperation of components. The contribution of the paper is that it brings our findings published “incrementally ” under one umbrella and articulates verbally what was elsewhere captured in an exact, formal way

Partial Verification of Software Components: Heuristics for Environment Construction

Code model checking of software components suffers from the well-known problem of state explosion when applied to highly parallel components, despite the fact that a single component typically comprises a smaller state space than the whole system. We present a technique that mitigates the problem of state explosion in code checking of primitive components with the Java PathFinder in case the checked property is absence of concurrency errors. The key idea is to reduce parallelism in the calling protocol on the basis of the information provided by static analysis searching for concurrency-related patterns in the component code; by a heuristic, some of the pattern instances are denoted as “suspicious”. Then, the environment (needed to be available since Java PathFinder checks only complete programs) is generated from a reduced calling protocol so that it exercises in parallel only those parts of the component’s code that likely contain concurrency errors

Behavior Protocols: Tolerating Faulty Architectures and Supporting Dynamic Updates

1.1. Component models- basic ideas.................................... 4 1.2. Describing behavior of components..................................